✨ Fiche d'Aide à la Décision

FAD

-

DOCUMENT D’ANALYSE FONCTIONNEL

-

FUNCTIONAL ANALYSIS DOCUMENT

Processus Achat

Microsoft Business Central

• 1. ANAL

Sommaire

1. Introduction 3

2. Vue d‘ensemble 4

3. Planification 5

4. Traitement d‘une livraison directe 6

5. Saisie d’une demande de prix 7

6. Saisie d’une commande cadre 8

7. Saisie d’une commande d‘achat 10

8. Saisie d’un retour d’une commande achat 12

9. Rapports achat 13

10. Historique achat 14

11. Annexe 1 : Liste d‘écarts 16

1. Introduction

Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :

• Visiter les sites clients comme les usines, entrepôts et/ou bureaux
• Conduire des ateliers orientés processus.
• Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
• Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
• Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
• Identifier les volumes des référentiels et données transactionnelles
• Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
• Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.

Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :

Versions du document

Liste de diffusion

1. Vue d‘ensemble
   1. Schéma d’ensemble des processus achat

Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :

3 Planification

3.1. Contexte et Hypothèses

Analyser le contexte actuel du processus d’achat : Almatech gère trois types d’achats – offres (devis), projets (demande d’achat) et achats génériques (licences, ordinateurs). Les achats sont mutualisés multi‑projet avec deux modes : « industrielle » (stock minimum, proposition, commande, livraison, ponction projet) – non déployé – et « spécifique » (achat par projet) ainsi que la variante « spécifique optimisée » (consommation du stock standard + achats complémentaires).

Identifier les difficultés : visibilité inexistante sur le statut de livraison, processus de réception « incoming » à revoir (localisation du colis, contrôle qualité, photos, gestion des NC bloquant la facture), absence de document d’entrée en stock, approbation verbale non formalisée, suivi des certificats limité aux pièces « VOL », manque d’intégration des coûts de transport et des dates de livraison, classification fournisseur non automatisée.

Clarifier les attentes : mise en place d’un workflow validation dans le journal des achats, suivi de la confirmation fournisseur, saisie de la date de livraison, intégration des frais de transport, création d’un warehouse receipt avec visibilité sur référence, quantité et rattachement à la commande, génération d’un quality control document avec photos, tracking lot/série et blocage de la facture tant que la validation qualité n’est pas effectuée.

Formuler les hypothèses :
- Le mode « industrielle » pourra être activé une fois le paramétrage du stock minimum réalisé.
- Les informations de lead‑time, vacances fournisseurs et transport seront disponibles dans le référentiel fournisseur.
- La catégorisation des fournisseurs par spécialité pourra être importée via Catya.
- Les documents associés aux devis (spécifications) seront stockés dans SharePoint et liés à la fiche article ou au purchase quote.
- Les champs Due Date, Requested Receipt Date, Shipment Method Code et Incoterm seront renseignés systématiquement sur le purchase order.
- Les lignes budget et project work package contiendront les dates de planification nécessaires au calcul des besoins.

[INFORMATION MANQUANTE]

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

3.2. Schéma des processus ERP : Planification 1.0

3.3. Principales règles de gestion

Valider la réception : à la réception d’une livraison (y compris partielle), créer un **document de contrôle qualité** lié à la **fiche article** concernée.

Imputer le paiement : le paiement s’effectue en avance ; le **journal des achats** doit enregistrer le montant avant la validation du contrôle qualité.

Gérer les certificats : le responsable Qualité contrôle les certificats via le **document de contrôle qualité** et, s’ils sont validés, le processus de réception passe à l’étape suivante.

Appliquer les instructions du Chef de Projet : le CP indique si le contrôle qualité doit être « léger » ou « approfondi ». Cette instruction déclenche le **workflow validation** qui oriente le niveau de détail du contrôle (photos, n° de lot ou série).

Exiger la ville pour les Incoterms : lorsqu’un Incoterm est renseigné sur la **commande d’achat**, le **workflow validation** impose la saisie obligatoire de la ville de destination.

Autoriser la réception différée du contrôle : il est possible de réceptionner les articles sans contrôle qualité immédiat. Le **document de contrôle qualité** pourra être complété ultérieurement au niveau des séries ou lots, puis validé par le responsable qualité, ce qui clôture la réception.

Contrôler les lots/ séries : si le suivi par n° de lot est paramétré, le **document de contrôle qualité** doit contenir le numéro de lot ou de série et les éventuelles photos demandées.

[INFORMATION MANQUANTE]

3.4. Documents et statistiques

Gérer le tableau de bord adapté au profil utilisateur pour afficher les informations pertinentes liées aux documents et aux statistiques de planification.

Intégrer les spécifications de documents dans SharePoint afin de centraliser les références et faciliter l’accès.

Scanner à la réception chaque pièce avec son document associé pour garantir la traçabilité des numéros de série et des lots.

Joindre la documentation requise à chaque demande de devis afin d’assurer la conformité dès la phase de planification.

Créer un document de contrôle qualité selon le type d’inspection :
- 1 document par série,
- 1 document par lot,
- 1 document par commande lorsqu’aucune série ou lot n’est défini.

Consigner les références de ces documents dans le système afin de permettre le suivi statistique des contrôles qualité et des entrées en stock.

[INFORMATION MANQUANTE]

3.5. Volume des données

Volume des données : [INFORMATION MANQUANTE]

3.6. Écarts critiques et interfaces

Identifier les écarts majeurs :

- Absence de **seuils dynamiques** dans la **fiche article** ou le **journal des achats** : le processus actuel ne permet pas de définir des seuils dépendant de la personne qui passe la commande ou du niveau de risque, contrairement aux bonnes pratiques qui exigent une configuration paramétrable.
- Manque d’**intégration du document de qualité** dans le flux d’achat : aucune interface n’ajoute automatiquement le doc de qualité au bon de commande, alors que le projet cible requiert la validation du document avant la création de la ligne d’achat.
- Aucun **mécanisme de blocage des livraisons** basé sur le statut qualité : le processus actuel ne bloque pas les livraisons lorsque le contrôle qualité échoue, alors que les exigences prévoient un **workflow validation** capable d’interrompre le processus logistique.
- Absence de **gestion des informations de lot** dans la **fiche article** : les données de lot ne sont pas capturées ni transmises aux étapes suivantes, ce qui contrevient aux exigences de traçabilité.
- Absence de **statut de blocage de la facture** en comptabilité : le processus actuel ne prévoit pas de statut qui empêche la facturation tant que la qualité n’est pas validée, contrairement aux exigences de contrôle financier.

Repérer les interfaces nécessaires :

- Interface entre le **journal des achats** et le **module qualité** pour transmettre le document de qualité et les seuils définis.
- Interface entre le **module qualité** et le **workflow validation** afin de déclencher le blocage des livraisons et la mise à jour du statut.
- Interface entre le **module qualité** et la **comptabilité** (facture) pour appliquer le statut de blocage de la facture lorsque la validation qualité échoue.
- Interface entre le **module qualité** et la **fiche article** pour enregistrer et diffuser les informations de lot.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

4 Traitement d‘une livraison directe

4.1. Contexte et Hypothèses

Analyser la situation actuelle : les achats Almatech couvrent trois catégories (offres / devis, projets / demandes d’achat, achats génériques) avec deux modes d’alimentation du stock (« industrielle » non déployée, « spécifique » ou « spécifique optimisée »). La réception des pièces se fait physiquement au bureau EPFL puis à l’atelier, sans visibilité sur le statut de livraison ni inspection systématique. Le processus « incoming » repose sur des photos du colis, une instruction du chef de projet (CP) pour un contrôle qualité léger ou approfondi, et la création éventuelle d’une NC ; la facture reste bloquée tant que la NC n’est pas résolue. Les certificats sont exigés uniquement pour les pièces VOL, gérés par le service Qualité Contrôle. Aucun document d’entrée en stock n’est généré, ce qui empêche le CP de savoir si les pièces sont reçues ou contrôlées.

Points critiques : absence de workflow validation pour l’approbation des achats (actuellement verbale), manque de suivi de la confirmation fournisseur et de la date de livraison, aucune intégration des frais de transport, visibilité insuffisante sur le « warehouse receipt » (référence, quantité, rattachement à la commande), contrôle qualité non automatisé, impossibilité de bloquer la facture via le statut qualité, gestion du multi‑sourcing et des incoterms non configurée, traçabilité lot/série partielle.

Attentes client : mettre en place un workflow validation dans le journal des achats, lier chaque « purchase quote » au numéro de projet, transformer la devis en commande en un clic, enregistrer la date de livraison et le champ Shipment Method Code (incoterm) avec ville, créer automatiquement un warehouse receipt, générer un document de contrôle qualité avec photos, lot/numéro de série et validation bloquant la facturation, intégrer les coûts de transport, offrir un tableau de bord exportable Excel et gérer les certificats selon le projet.

Hypothèses impactant le projet : le CP continuera à fournir les instructions d’« incoming », les pièces seront classées en trois types d’articles (en stock, non‑inventory, service) dans la fiche article, le référentiel fournisseur contiendra lead‑time, MOQ et spécialité, les certificats seront requis uniquement pour les pièces VOL, la configuration du multi‑sourcing et du fournisseur préféré sera réalisée avant la migration, et les sites de stockage (EPFL, Payerne, autres) seront intégrés au module gestion des entrepôts.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0

4.3. Principales règles de gestion

Valider la réception dans le **journal des achats** en appliquant les règles suivantes :

- **Paiement en avance** : le processus exige que le paiement soit enregistré avant la création du **document de contrôle qualité**. Business Central bloque la validation de la réception tant que le paiement n’est pas présent dans le **journal des achats**.
- **Gestion des certificats** : le responsable Qualité crée un **document de contrôle qualité** lié à la **fiche article**. Ce document recense les points à contrôler, les photos requises et, si le suivi par lot est activé, le numéro de lot ou de série.
- **Instruction du Chef de Projet** : le CP indique, via le **workflow validation**, si le contrôle doit être « léger » ou « approfondi ». Le workflow dirige la tâche vers le responsable Qualité avec le niveau de contrôle choisi.
- **Incoterm** : dès qu’un Incoterm est renseigné sur la **livraison directe**, le système impose la saisie obligatoire de la ville de destination avant de permettre la validation.
- **Contrôle qualité** : le responsable Qualité valide le **document de contrôle qualité**; la validation déclenche automatiquement la validation de la réception dans le **journal des achats**.
- **Réception partielle** : Business Central accepte la réception partielle et crée un **document de contrôle qualité** distinct pour chaque lot ou série non contrôlé, permettant de réaliser le contrôle ultérieurement.
- **Possibilité de différer le contrôle** : l’utilisateur peut enregistrer la réception sans contrôle immédiat ; le **workflow validation** garde la réception en état « en attente de contrôle » jusqu’à la validation du responsable Qualité au niveau des séries/lots.

4.4. Documents et statistiques

Imprimer le **document de contrôle qualité** à chaque réception :
- Générer un **document d’inspection** par numéro de série lorsqu’il existe ;
- Générer un **document d’inspection** par lot lorsque la marchandise est groupée ;
- Générer un **document d’inspection** par commande si aucune série ni aucun lot n’est défini.

Imprimer la **documentation à joindre à la demande de devis** dès la création de la proposition client.

[INFORMATION MANQUANTE] concernant les impressions de bordereaux d’entrée en stock : aucun document d’entrée en stock n’est actuellement généré.

Collecter les scans des documents à la réception pour assurer la **traçabilité** des pièces ; les scans sont associés aux pièces dans le système.

Fournir, via le **tableau de bord adapté au profil utilisateur**, les états et statistiques métiers attendus :
- suivi du nombre de documents de contrôle qualité créés (par série, lot, commande) ;
- taux de conformité des inspections ;
- visibilité des pièces scannées et associées aux livraisons ;
- indicateurs de pièces jointes aux demandes de devis.

[INFORMATION MANQUANTE] sur les indicateurs de performance supplémentaires (délais de traitement, volumes de livraisons, etc.).

4.5. Volume des données

Indiquer [INFORMATION MANQUANTE]

4.6. Écarts critiques et interfaces

Définir le seuil de blocage : seuil dépendant de l’utilisateur qui passe la commande ou du risque associé, à configurer dans le paramétrage de la **livraison directe**.

Intégrer le document de qualité : ajouter obligatoirement le document de qualité au moment de la réception pour déclencher le contrôle de conformité.

Bloquer les livraisons : mettre en place une règle de validation qui empêche la validation de la **livraison directe** tant que le document de qualité n’est pas présent ou que le lot ne respecte pas les critères définis.

Gérer les statuts de qualité : créer un statut « Qualité non validée » qui, dès son affectation, bloque la génération de la facture dans la **comptabilité**.

Interface : liaison entre le module **Gestion des lots** et le module **Comptabilité** pour transmettre le statut de validation qualité et appliquer le blocage de facturation.

[INFORMATION MANQUANTE] – Objet BC exact à utiliser pour la configuration du seuil (ex. : « paramètre de seuil »).

[INFORMATION MANQUANTE] – Interface précise avec le module **Qualité** (ex. : service web, API).

[INFORMATION MANQUANTE] – Workflow de validation à associer (ex. : « workflow validation »).

Ces écarts critiques et interfaces seront inscrits dans la liste des écarts livrée à la fin de la phase d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

1. Saisie d’une demande de prix

5.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

• 1. Schéma des processus ERP : Demande de prix 3.0

5.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

5.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

5.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

5.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

6 Saisie d’une commande cadre

6.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0

6.3. Schéma des processus ERP : Saisie d’une commande d’achat

6.4. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

6.5. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

6.6. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

6.7. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

7 Saisie d’une commande d‘achat

7.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

7.2 Schéma des processus ERP : Saisie d’une commande d’achat

7.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

7.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

7.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

7.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

8 Saisie d’un retour d’une commande achat

8.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0

8.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

8.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

8.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

8.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

9 Rapports achat

9.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

9.2 Schéma des processus ERP : Rapport achat 8.0

9.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

9.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

9.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

9.6. Ecarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

10 Historique achat

10.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

10.2 Schéma des processus ERP : Historique achat 9.0

10.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

10.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

10.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

10.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

11 Annexe 1 : Liste d‘écarts

11.1. Liste d’écarts

La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.

Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).